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£. IN@RODUCTION 


A. GENERAL 

Computer networks are an important part of our scciety 
and directly or indirectly affect many people. In recent 
years, there has been considerable interest in studies 
related to a special kind of network, the Local Area Net- 
works (LAN), and it is reasonable to expect a proliferation 
of LANs within the next decade, due to new technologies 
and potential applications. 

One major attraction of LANs is that they make possible 
the economical and efficient sharing of resources, i.e., 
processors, expensive peripheral devices, databases, communi- 
Cations bandwidth, information, etc. Because of the grow- 
ing complexity of the Navy's logistics functions, the 
zncrease in the number of above mentioned resources, and the 
need to support interactive operations at the Navy's stock 
points and inventory control points, have led the developers 
er the Supply Point Logistics Integrated Communications 
Environment (SPLICE), to employ a local area network at each 
Site for integration cf all computer resources [Ref. 1]. 
Also this local area network will serve as the basic linkage 
for future system integration within a designated location 
(Ref. 2]. That is, as SPLICE requirements evolve and as 


technology changes, dissimilar devices e.g., new host computers, 
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mass storage devices, teleprocessing gateways, can be added 
co, thie LAN easily without having to redesign other parts of 
the SPLICE system. 

The SPLICE project at the Naval Postgraduate School will 
produce specifications and recommendations for the design of 
the LAN to be implemented at stcck points and inventory con- 
trol points. During the design phase of any system a simula- 
tion model has proven to be an effective analytical tool to 
assist in the decision making process. Simulation modeling, 
though based heavily upon computer science, mathematics, proba- 
Paewey, ana statistics, remains an intuitive process [Ref. 3]. 
The following quotation of R. E. Shannon [Ref. 3] stresses 
a note of warning about simulation: "Like all powerful tools 
which depend heavily upon art in their application, simulation 
is capable of giving either very good or very bad results, 
depending upon how it is used. It can either enlighten or 
misiead." This thesis covers work done toward the develop- 
ment of such an effective tool, a simulation model for local 
area networks design. 

1. Scove of Research 

Although simulation models differ significantly in 
their construction and use, the analysis and development of 
all types consists of three general phases: Conceptualiza- 
tion (specifications), implementation, and experimentation. 
Towards the development of a complete simulation model for a 


lecal area network implementing the SPLICE functions, this 
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research covers the conceptualization phase by discussing 
the specifications of such a model. 
2. Approach 
The development of specifications of the LAN simu- 
lation model went through clearly definable but overlapping 
and frequently iterative steps. A brief discussion of each 
step taken in the development process follows: 

a. Study system simulation in general: A general study 
of system simulation was conducted for the purpose of ob- 
taining a Knowledge of general system simulation and select- 
ing an appropriate simulation technique to be used with the 
LAN simulation model. 

D. Stucy LAN components and performance measures in general: 
LAN components and performance measurements were investi- 
gated in order to develop a knowledge and understanding of 
wnat actually composes a LAN and determine the different 
types of performance measures which could be made on com- 
puter networks in general. Such investigation was necessary 
for the development of an accurate LAN simulation model. 

Ge Gling Specifications ‘for a particular LAN simulation 
model: This third step in the development process was con- 
cerned with the detailed design of a LAN simulation model. 
That is, the symbolic (logical-mathematical) description 
of a local area network system to the level of detail 
@eeeorriate to give a valid representation of the system. 

G. Stucy model implementation and experimentation: This 


final step in the development process, though not within 
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Gree ecope Of the thesis, was conducted in order to obtain 

a knowledge of these two important phases in simulation 
model construction. This knowledge was necessary in deter- 
mining the level of LAN system resolution to be represented 


in the simulation model. 


B. OVERVIEW 

Following the steps taken in the development process of 
a Simulation model, this thesis discusses, first, in Chapter 
II the development of a system simulation. Next, in Chapter 
III, are discussions of the various components which make up 
a local area network and different performance measures are des- 
cribed. Then, in Chapter IV, the specifications of a simulation model 
for a local area network are given. Finally, Chapter V is 
concerned with the implementation and experimentation phases 


Of game aAtion model construction. 
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SS LEM Oot MU LAT LON 


One of the most important and useful tools for analyzing the 
Gesign and operation of complex processes or systems is simula- 
tion. Simulation is a very wide-open and somewhat not well de- 
fined subject of great importance to those responsible for the 
design of systems as well as those responsible for their operation. 

In general usage, simulation is defined as an act or 
process that gives the appearance or effect of some part of 
Beawity—--a counterfeit, a feigning [Ref. 4]. Among the many 
Gefinitions offered by various authors, the more suitable 
for the purposes of this thesis is given by Shannon [Ref. 3]: 

Simulation is the process of designing a model of 

a real system and conducting experiments with this 

model for the purpose either of understanding the 

behavior orf the system or of evaluating various 

strategies (within the limits imposed by a criterion 

Or set of criteria) for the operation of the system. 
Thus, it is understood that the process of simulation includes 
both the construction of the model and the analytical use of 
the model for studying the system. 

Topics relevant to a fundamental study of simulation are 
those that deal with and define the key words in the above 
Gefinition: system, model. This chapter describes the 
basic concepts of what constitutes a svstem, how a model 


can be used to represent a system, and how a system and model 


description affect the development of system simulation. 


&. SYSTRMS 


Webster's New Collegiate Dictionary (1980, p. 1175) 


defines a system as "a regularly interacting or interdependent 
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roup cf items forming a unified whole." For the purposes 
of this thesis a more specific and operational definition 
will be used, given by Fitzgerald [Ref. 5]: 
A system can be defined as a network of interrelated 
procedures that are joined together to perform an 
activity or to accomplish a specific objective. It 
as in effect, all the ingredients which make up the 


whole. And a procedure is a precise series of step- 
by-step instructions that explain 


* What is to be done. 

- Weo will do it. 

““Wherwirt will be done. 

- How it will be done. 

Systems are distinguished from one another by their static 
ama Gynamic structures. The entities (i.e., a job) that make 
up a system, along with their associated attributes (i.e., job 
priority) and membership relationships (conncection between 
entities) define its static structure. The activities in which 
these entities engage specify its dynamic structure. The re- 
iationships between the attributes of a given entity are called 
functions and very often are being given in some form of mathe- 
matical expression. Collectively, the attributes (i.e., their 
values) of an entity define its states, and the states of the 
entities of a system define the state of the system. These entity 
States can be viewed from both a static or dynamic system 
standpoint and pvrovide a significant tool for examining system 
behavior. That is, they can be viewed at a single point in 
time or over a series of points in time. 
Every system has three basic features. It has an environment 

im Wien it exists. It has a set of boundaries which distinguish 


the system from the rest of its environment. And it has a 


set of subsystems which are its components parts [Ref. 6]. 
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1. Objectives for Analyzing a Svstem 


The objective in studying system behavior are to learn 
Pewywene state transitions occur, to predict transitions in state, 
andto control state transitions. One way inwhich these objec- 
eawes Can be satisfiedis through the evaluationof alternatives 
[Ref. 6]. An evaluationof alternatives approach is concerned with 
the relationship between system inputs, which induce transitions in 
state and system outputs which measure these transitions in state. 

There are three common properties tothe evaluation of the 
alternative approach: The firstisa straightforward analysis in 
which the system and its inputs are specified and the outputs are 
then measured. The second is broader in purpose and canbe used 
to evaluate the relative meritsof alternative system design 
when input is given and certain desirable characteristics for the 
Output are specified. The third and final variantiswhen the 
system is specified and an effort is made to determine the 
[etemcnae produces the desired output. In this research, a 
combination of the second and third approaches is used. 

2. Svstem Classification 

Systems canbe classified inanumber of ways [Refs. 4,5,6]. 
Unfortunately, none is completely satisfactory, although each serves 
@ Sartreular purpose. Some of these classification schemes 
are as follows: 

a. Natural vs Man-made 

The distinction between the two is obvious. 
Bp. Open vs Closed 
The distinction here is not so obvious. A closed 


system is one which automatically controls or modifies its 
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Own operation by responding to data generated by the system it- 
self, thus it is one which can exist in a number of alternative 
environments. An open system, on the other hand, is one which 
does not provide for its own control or modification, thus it 
is one which only exists in a particular environment. 
c. Discrete vs Continuous 

The distinction between the two depends upon the way 
that they change from one state to another. The distinction can 
best be seen by considering the values that can be taken on by 
the variables that characterize the state of the system [Ref. 4]. 
Continuous systems include variables that can take on any real 
value in a prescribed interval or intervals. Discrete systems 
mnctwe@e Variables that can take on only one particular value 
from amonga finite (but possibly very large) set of values. 

ad. Deterministic vs Stochastic 

The distinction between the two depends upon the 
causal relationship between input and output. The output of a 
deterministic svstem can be predicted completely if the input 
and the initial state of the system are known. That is, fora 
particular state ofthe system, a giveninput always leads to the 
Same output. Astochastic system in a given state, onthe other 
hand, may respons toagiven input with anyone among a range of 
Gistribution of outputs. Forastochastic system--given the input 
and the state of the system--it is possible to predict only the 
fane@e within which the output will fall and the frequency with 
which various particular outputs will be obtained over many 
repetitions of the observation. It is impossible to predict 


Gime particWlar output of a single observation of the system. 
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e. Adaptive vs Non-adaptive 

As their names imply, these systems either can 
or cannot react to changes in their environment. 

The above distinction takes on real significance 
when the system is being analyzed. Conclusions reached about 
an open system must be carefully qualified in terms of the 
system environment. Also the analysis of an adaptive system 
requires a complete description of how the system environment 
causes changes in system state. 

Secs cem State 

The state of a system is determined by the values of 
the attributes of the system entities. Depending on the view 
concerning activities, whether they interact at discrete 
points or over periods of time, there can be attributes asso- 
Clated with dynamic as well as static system structures. That 
1S, an activity can be fully or partially completed, be in 
progress or terminated, be waiting for another activity to 
G@@eur Gr be interrupting another activity, etc. In a general 
vyliew, there is no conflict in the description of state as a 
Static or dynamic phenomenon, since at all times, whether 
between state changes in a static structure, or at system 
@Geivarty interactions in a dynamic structure, the concept of 
a system state is completely defined. 

Viewed at a point in time, a system is always in one 
of a number (perhaps ennormous) of states. Viewed over a 


period of time, a system passes through a succession of states 
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as its entities undergo system activities, change their 
attribute values and relationships, and become Sele plo ischa 
subsequent activities. Thus, the analysis of a given svstem 
is the study of its transitions in state as time passes. 

The state transition of a system is described by two 
attributes (i.e., their values): magnitude and delay [Ref. 
6]. The magnitude of a state transition refers to the abso- 
lute difference in an attribute's value over a specified period 
of time compared to its value before the state changes. The 
@-tay associated with a transition of state refers to the 
passed time between the arrival of an input and the actual 
transition of state caused by the input. Delay determines 
that an input can cause a transition state immediately upon 
its arrival, at some time after its arrival, or over a period 
Sreerme following its arrival (continuously). 

4. Svstem Response 

When viewed together, the magnitude and delay ina 
transition of state describes system response. That is, the 
wey in which the system reacts to a given input. Five possible 
System responses are shown in Figure 2.1 [Ref. 6]. A stable 
system response is shown in Figures 2.la, 2.1b, and 2.lc. In 
a stable response, tne system moves over some finite period 
of time to a permanent new state of equilibrium (steady state) 
of finite value as a result of a single input to the system. 

Two definitions are important in considering when to 


begin to measure output in a Simulation experiment: 
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Magnitude 


a. No Delay 


Time 


b. Delay 


eG. Stable Response 


ad. Unstable Response 





e. Unstable Nonexplosive 


Serm@lus came 
Figure 2.1. Possible System Responses 
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a. The system is said to be in the empty or idle state, 
if the initial value of the state variable under considera- 
tien is zero. 

b. The system is said to be in a transient Stateye if ake 
is in the process of moving from one Steady state to another. 

Results, as a general rule, should be taken only 
after a steady state is reached, following the transition 
period from an initial empty or idle system state. This 
reduces the influence of the systems behavior during the 
transition period on the overall evaluation of the system. 
an unstable system response is shown in Figures 2.1ld, and 2.le. 
Figure 2.ld exhibits an explosively unstable response where 
pac Vemme Of the state variable continues to increase with the 
time without convergence to a new finite value. Figure 2.le 
shows a non-explosive unstable system in which an equilibrium 
level exists but where system response oscillates around this 
level but does not converge to it. 
59. Svstem Performance 
Farlier, three objectives were given for analyzing a 

system. They were to learn how system state transitions occur, 
E@ @ecemcte transitions in state, and to control transitions 
in state. These specific objectives for system analysis re- 
sult from a desire or need to improve system performance. 
In turn, system performance is reflected in the sequence of 
States that a system undertakes over a given period of time. 


Normally, these sequences of system states are manipulated 
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in some way by the system analyst to provide a series of 
performance measures. 

The idea of what composes a performance measure varies 
with the system. For example, in Chapter III of this thesis 
the essential measures of Local Area Networks (LAN) perfor- 
mance will be discussed. These measures would have little 
or no significance if they were applied to the evaluation 
of another system (e.g., Water resources system). 

In conducting the analysis of a complex system, it 
is often desired to obtain only a "feel" for system perfor- 
memec. It is exactly this type of analysis effort that can 
greatly benefit from a careful consideration of which per- 
formance measures will provide the needed "feel" or under- 
Sstancing of the system. Failure to devote adequate time to 
determine the verformance measures that will be used can lead 
to confusion and delay in the analysis process. 

6. Svstem Optimization 

One objective in analyzing a system and in measuring 
its performance is to optimize system performance, that is, 
tO improve the effectiveness of the system. Generaily, this 
system optimization involves the identification of certain 
critical system aspects and the development of certain pro- 
cedures to control these aspects. Usually, however, a number 
of these critical system aspects are beyond the analyst's 
observation. Such aspects put constraints on system behavior 


prem p=event total system optimization. In this case the 


a 





final objective must be modified to one of optimizing 
performance under certain constraints. As it is often the 
case with the large complex systems, optimization of the 
entire system is virtually impossible, due to the size of 
the system and the complexity of the relationships among 
the various subsystems. Thus, optimization can and must 
occur with regard to individual subsystems or selected 


groups of subsystems. 


B. MODELS 

The initial step in analyzing a system beyond defining 
system components and identifying possible performance 
measures, is to build a model of the system. 

A model is a representation of an object, system, or 
eae, im some form other than that of the entity itself. Its 
purpose is usually to aid in explaining, understanding, or 
improving a system [Ref. 3]. 

1. Function of Models 

The concept of representing some object, system, or 
idea with a model, is so general that it is difficult to 
classify all the functions that models perform. Fishman 
{Ref. 6], recognizes that a model performs the following 
Eumetions: 

a. Enables an investigator to organize his theoretical 
beliefs and empirical observations about a system 
and to deduce the logical implications of this 
Organization. 


b. Leads investigator to improved system understanding. 
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c. Brings into perspective the need for detail and 
relevance. 


d. Expedites the speed with which an analysis can be 
accomplished. 


e. Provides a framework for testing the desirability 
of system modifications. 


f. Is easier to manipulate than the system is. 


Cin Permits control over more sources of variation than 
direct study of a system would allow. 


foeetoegenerally less costly. 

Summarizing the above functions, a model may serve one 
of two major purposes: descriptive, for explaining and/or 
understanding, and prescriptive, by predicting and/or 
G@uelweatang behavior characteristics. 

2. Model Classification 

Models can be classified in a variety of ways and 
can take many forms. A model can be: 

a. Iconic like a scale model airplane. This model resem- 
bles the system being studied. 

b. Analog like an electric circuit that behaves like a 
mechanical system. In this model a property of the real 
system is represented by a substituted property which often 
behaves in a similar way. 

c. Symbolic lixe a set of equations. This model uSes a 
symbol rather than a physical Gevice to represent an entity 
of the system. 

Iconic models are good visual aids but are usually not good 
g@ueoreaiceing or explaining the behavior of the systems. 


Symbolic models are good for prediction and explanation but 
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offer little as visual aids. Thus, different models exist 
for different purposes. This thesis concerns itself with 
Symbolic models, so a further classification of those models 
tollows. 
3. Symbolic Models 

A symbolic model represents a system using mathemati- 
cal equations and algorithms. Symbolic or mathematical 
models can be distinguished according to their characteris- 
tics into four classification schemes as follow [Refs. 6, 7, 
Be oO} 

a. Analytical vs Numerical 

In an analytical model it is possible to deduce 

the behavior of the system, directly from the system's mathe- 
matical representation. Kirchoff's law is an example of 
an analytical model. A numerical model implies that an exact 
Geduction of the system's behavior is not feasible but 
numerical methods can provide descriptions of the behavior for 
certain system aspects as are defined in the numerical model. 
Numerical integration is an example of a numerical model. 

b. Continuous vs Discrete 

Continuous-change models are used to represent 

systems that consist of a continuous flow of information or 
material (e.g., flow of gas in a pipeline). Continuous models 
are usually represented by differential equations which des- 
Cribe rate of change of the variables over time. Discrete- 


change models represent systems in which changes in the 
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state of the system are discrete (e.g., messages arriving 
at a node of a network). Discrete models are usually repre- 
sented by queueing theory and stochastic processes. 

SG. “Static vs Dynamic 

A static model either does not take into con- 
sideration the passage of time or describes the state of 
a“system at a specified point in time. On the other hand, 

a dynamic model explicitly recognizes the passage of time. 
A cynamic model may specify also the relationships between 
the various system states at different points in time. 

d. Deterministic vs Stochastic 

In a deterministic system model, all the entities 
of the system have fixed mathematical or logical relation- 
ships to each other. Thus, the behavior of the system is 
completely determined by these relationships. In a stochas- 
tic model, part of the entity relationships, at least, vary 
@i a Fandom fashion. Thus, an analyst can at best, obtain 
an average description cf a system behavior by using a 
stochastic model. 

There are a number of different model descriptions 
peSeible, when the four sets of model characteristics are 
combinec. 

4. Scone of a Model 
A model is used to predict results and describe the 
way the results are determined when a set of input conditions 
is given; that is, the analyst is concerned with both system 


response and system dynamics. 


206 








During the model building process the analyst must 
continuously deal with the problem of balancing the need for 
structural cetail in describing the system, with the modeling 
resources and capabilities available. By its nature, a sys- 
tem model is a formalized abstraction of reality, thus the 
more structural detail it includes, the more it resembles the 
actual system. Additionally, increased modeling detail pro- 
vides an increased capability for observing system response 
in a given system modification or series of system modifica- 
GHomee (Ret. 10}. That is, imereased detail provides more 
combinations of system modifications which can be made and 
more aspects of system response which can be measured. 

While it seems to be desirable to include as much 
modeling detail as possible in a model, there are several 
problems which result from this increased detail. First, 
increased detail makes the modeling process more difficult. 
Second, it usually shifts the model characterization from 
analytical to numerical. Third, and most important, the 
analyst often does not understand the system to a degree that 
Will allow specification of the system in the desired detail. 
Fourth, and final, the inclusion of increased detail may place 
an increased and unacceptable demand on analysis resources, 
i.@€., time, personnel, facilities, etc. 

Every type of system model must limit the amount of 
structural detail it includes. The degree to which this de- 


tail is limited must be determined through a process of 
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balancing the original system analysis objectives against 
the analysis resources. 

Although one of the purposes of building a system 
model is to improve the analyst's understanding of the sys- 
tem, there are three hazards associated with achieving this 
purpose [Ref. 6]: First, there is no guarantee that the 
results of the modeling effort will prove to be useful. 
Sometimes this type of failure is due to a lack of adequate 
resources, but more often, it is a case of an improper 
balance between available resources and the system analysis 
objectives. The second hazard deals with the analyst him- 
self, who may think of his particular description of the 
System as the most accurate representation of reality, when, 
an feet, 42t isemet. The third endemost critical hazard in- 
volves the use of the model to analyze aspects of the system 


which the model was not intended to analyze. 


e. BISGRETE EVENT SIMULATION 

This section presents concepts applicable to the con- 
struction of a discrete event simulation model. An event 
denotes a transition in the state of a svstem entity. Thus, 
a discrete event simulation model can be defined as a model 
of system behavior in which entity state transitions are 
represented as a series of events occurring at discrete 
points in time. 

Following is a discussion of event timing and entity- 


attribute relationships. The purpose of the discussion is to 
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establish their importance in the realization of a discrete 
event system model. Additionally, alternative discrete 
event modeling techniques are discussed. 

l. Event Timing 

The actual approach to the discrete event modeling 
of a particular system depends on the nature of the event's 
inter-arrival rates. That is, whether these inter-arrival 
Bates) ake determminastic or random in nature. If the inter-~ 
arrival rates are deterministic, then the modeling techniques 
used must reflect inter-arrival rates which vary according 
Ge w Gexed relation or are equal. If the inter-arrival rates 
are random, then the modeling techniques must reflect their 
randomness. 

With either type of inter-arrival rate, the occurrence 
of an event specifies a transition in the state of the system. 
The states of system entities remain constant between the 
occurzence of events, so there is no need to account for 
this dead time in a discrete event system model. When a 
particular event occurs and all the state transitions asso- 
Ciated with the event are made, then simulated time is advanced 
to the time of the next event, where once again the required 
state transitions are made. This next event technique allows 
the analyst to compress time. 

2  Entity-Attribute Relationships 
There are two types of primary structural relation- 


Ships woich play a significant role in the modeling of a 
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system. The first are the mathematical relationships which 
exist between the attributes associated with the various sys- 
tem entities. Sometimes the specification of the mathemati- 
cal relationships for a system serve to describe completely 
the way in which system state transitions occur. The second 
are the logical relationships which exist between system com- 
ponents. A logical relationship checks to see if a certain 
condition holds. If it does, a given action is taken. If 
it does not hold, an alternative action is taken. Normally, 
a system is not modeled through the use of only one type of 
Pee tOnonip, but through a mixture. 
3. Alternative Modeling Techniques 

There are three main ways of building discrete event 
system models [Ref. 6]. 

a. The event scheduling technique emphasizes the detailed 
Gescription of the steps that occur during the processing 
Sememeevent. Usually, an event naturally has a distinct 
Series of steps associated with it. 

Db. The activity scanning technique emphasizes the review 
of all activities in a simulation to determine which can be 
initiated and terminated during the occurrence of a given 
evemt . 

freemen, the process interaction technique emphasizes 
the continuous progress of an entity through the system. 
That is, from its arrival event to its departure event. 

The development of the three techniques mentioned 


above has been associated directly with the development of 
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discrete event simulation programming languages. In particu- 
lar, GASP and SIMSCRIPT use the event scheduling technique, 
GS uses the activity scanning technique, and GPSS and 
plem@ULA use the process interaction technique [Ref. 4]. 

4. Queueing Models 

The majority of discrete event simulation models are 
reducible to a series of queueing problems. In a queueing 
problem, an arrival event occurs and causes an entity to 
Gemand a service to be performed. The system responds to 
the demand for service either by performing it or by keeping 
mmo Cmeity waiting (puts it in a queue) until it can per- 
form the required service. 

The objective in queueing oriented problems is usually 
to analyze how system performance varies in response to 
changes in svstem workload, system resource characteristics, 
or task selection schemes. In a given workload, system 
resources, and task selection must be resolved and explicitly 


specified in the simulation mocel. 
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Ifft. LOCAL AREA NETWORK COMPONENTS AND PERFORMANCE MEASURES 


A. GENERAL 

A computer network, in general, is any system composed of 
one or more computers and associated terminals, communica- 
tion devices, transmission facilities, and software/hardware 
to facilitate the flow of information between terminals and/ 
Or computers. 

Metcalfe and Boggs [Ref. 11], distinguish three types of 
networks based on the parameters of bit rate and separation 


between computers: 


Aebivity Separation Bit Rate 

Remote networks a0 Km < 0.1 Mbit/sec 
Local networks 0.1--10 Km O0.1--10 Mbit/sec 
Multiprocessors < 0.1 Km > 10 Mbit/sec 


At one end of the above spectrum of activities there is 
a group of dissimilar computers tied together by a communi- 
cation network, which enables a user to take advantage of a 
variety of computing resources, while at the other end there 
is an attempt to convert a collection of serial processors 
into parallel processors. Since local networks are near the 
middle of this spectrum, they may be built to gain the re- 
source sharing of computer networking along with the parallel- 
ism Of multiprocessing. 

7. GAN Definition 

As its name implies, a LAN links computing system 


components located within a geographically restricted area, 
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such as a building or an office complex. There is no widely 
acceptable definition for a LAN. It should be noted that a 
pamet discussion held during the Third Conference on Local 
Computer Networks--a conference devoted to develop a defini- 
tion of a local computer network--failed to achieve a defini- 
Efem acceptable to all participants. A definition for local 
networks, which has been proposed by Franck [Ref. 12], is 
given below. He pictures a local computer network as con- 
Sisting of three essential ingredients: 

a. A high-speed transmission medium for data transmission 
over a "limited" distance. The nature of the transmission 
medium and the topology of the network are left unspecified. 

b. Several network adapters attached to this transmission 
medium which serve as line interfaces for computing equipment. 
The adapters transmit data on the transmission medium. 

c. Computing system components that can be attached to 
an adapter. 

Peamex's ildustration of his definition is shown in Figure 
ae 
2. Overview 

Based on the previous definition certain topics rele- 
vant to a fundamental study of the LAN components are those 
that deal with and define the key words: topology, physical 
transmission medium, and communication protocols for network 
management. To accomplish an effective network management 


is is essential that a series of basic transmission COnELO! 
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procedures be established to ensure the efficient and accurate 
transfer of information within the network. These procedures 
calied network protocol, along with related aspects as 

cNannel access, flow control, and error control are exten- 
sively covered in Ref. (18) and not included here. 

This chapter will discuss in general, the LAN 
topologies, the transmission medium, and the network perfor- 
mance measurements which are fundamental ingredients in any 
LAN analysis or design effort. It should be noted that the 
specific characteristics of the network components depend 


greatly upon the manner in which the LAN is implemented. 


B. TOPOLOGY 
Network topology is the spatial pattern formed by a net- 
work's digital devices, called nodes, and connecting links. 
Many characteristics of computer networks are determined or 
influenced by their topology. Some qualitative attributes 
can be inferred directly from the topology of the network 
independently of the particular implementation [Ref. 13]. 
Suaeh attruabutes, among others, may be: 
1. Modularity, the ability to make incremental changes in 
system capability. 
2. Flexibility which measures the degree of freedom in 
adding a new element to the network. 
3. The ability for graceful degradation. 
As the number of network elements increases, the number 


of ways one can interconnect the various elements increases 


32 





rapidly. Thus, it is not easy to classify all possible 
topologies for a network. This section will discuss only 
the basic topologies used in computer networks: Bus, pag) slog 
star, and mesh. The bus and the ring are characteristics of 
new decentralized network schemes intended for computer com- 
munications. The star is widely used in long-distance net- 
works and in conventional (centralized) local networks, such 
as time-sharing systems. The mesh is characteristic of long- 
distance packet-switched (decentralized) networks. 

1. Bus Topology 

The bus topology employs a shared transmission 
facility, called a bus, for information exchange between 
several nodes (computers, peripherals). Figures 3.2a and 
3.20 illustrate distributed and centrally controlled bus 
topologies [Ref. 14]. In Figure 3.2a, all nodes are identical 
in nature but a technique must be developed to eliminate 
Gemetentrten fer the use of the bus. In Figure 3.2b, a single 
control node manages the traffic flows between every pair 
of nodes, i.e., all nodes must communicate with control node 
C before they set up a call. 

The bus itself is employed in a broadcast moce, all 
nodes "hear" a message. The major advantage of a bus topology 
is its simplicity. It is easv to add or delete processing 
elements and by using passive connections the reliability is 
improved. The principai disadvantage of this topology is 


mee vwadinerability of the network to a failure of the bus 
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Figure 3.2. Bus Topology 
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itself. However, nodal failures will generally have no 
impact on the operation of other nodes. 
2. Ring Topology 

A network topology 1s characterized as ring, if a 
collection of processing elements (computers, peripherals) 
are interconnected via a communication path in the form of a 
loop. Two varieties of loop, or ring, topology are shown in 
Pag@res 3.3a amd 3.35 [Ref. 14]. In Figure 3.3a, each node 
acts aS a message store~-and-forward node. In Figure 3.3b, 
each node receives bits only in assigned time slots. If all 
nodes of the loop are of the same type, a distributed ring 
topology results, but if one node is a loop supervisor then 
a Gentrally controlled ring topology results. In general, 
traffic on the loop flows in one direction only and so a 
break in the loop at any point disables it. Consequently, 
each connection to the network is complex because hardware 
1s required to keep the network functioning even when a node 
fails. 

3. Star Topology 

A star topology is characteristic of many conven- 
tional local and long-distance networks. This arrangement 
connects each station to a central facility responsible for 
managing all communications. Its structure is shown in Figure 
3-4. Both the advantages and disadvantages of this topology 
arise from this centralization. Communications and resource 


management can be efficiently handled, but the limitations 
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a. Serial Store-and-Forward Ring Topology 


-D. BrE@edeest Ring Topology 


Figure 3.3. Loop or Ring Topology 
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Puere 3,4. Star Topology 


Figure 3.5. Mesh Topology 
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and reliability of the central unit determine all the net- 
work performance characteristics. 

4. Mesh Topology 

A mesh topology is widely used in long-distance 

decentralized ("packet-switched") networks. In this 
arrangement all the nodes are connected arbitrarily as shown 
in Figure 3.5. The star and the mesh topologies frequently 
appear in combination in long-distance networks. That is, 
a mesh network may serve as the hub of a subsidiary star 
network. By providing alternative routings, the Mesh topology 
has relatively high reliability, and it allows for uncon- 


strained network reconfiguration. 


C. TERawoe2SSION MEDIUM 

Though the topology selected determines many network 
issues, it is Dasically independent of the choice of the 
transmission medium. The transmission medium provides the 
physical data communication links of the network, i.e., high 
speed oaths for electrical transmission between two or more 
nodes or terminals. Generally, local networks can use an 
assortment of media which are technologically appropriate to 
a Given application. 

The four most frequently used transmission media in LAN 
are: twisted wire-pair, fiber-optics, baseband coaxial cable 


and broadband coaxial cable (TV-cable). 
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Twisted wire-pair is basically used to connect stations 
in a low-speed network where the required bandwidth does not 
exeGeed 19 Kbits per second [Ref. 15]. 

Piber-optic cable ailows the construction of very high 
performance and secure networks. The advantages of fiber- 
optic are many, and its potential is very promising. 
Generally it can provide [Ref. 16]: 

1. High-speed data transmission capability (up to one 
gigabits per second). 

2. Relative immunity to electromagnetic and radio fre- 
quency interferences. 

Be ShulclWwer degree of communication security. 

4. Large reduction of the bit error rate (one bit per 
billion). With current technology the fiber-optic cable is 
not a practical medium for bus networks because of the lack 
of cable taps. 

Most local computer networks use coaxial cable because 
it allows very high data rates over Gistances up to several 
miles without signal regeneration. A coaxial cable is used 
to support either a baseband channel or a broadband channel. 
In the first case the coaxial cable provides a single channel 
1.e€., Gigttal signals are placed directly on the cable. In 
the second, the cable's bandwidth is divided into a number 
of independent channels by employing Frequency Division 


Multiplexing (FDM) techniques. 
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D. PERFORMANCE MEASURES 

A basic understanding of computer network performance 
measurement is essential during the computer network analy- 
Sis cycle, 1.e., from problem definition to simulation ex- 
perimentation. However, the measurement of computer network 
performance is difficult and sometimes totally qualitative 
in nature. This happens due to the great number of different 
components (hardware and software) that are included ina 
computer network. 

in order to evaluate a network effectively, a set of 
performance measures must be employed. This set must encom- 
pass the network topology, communication devices, transmission 
facilities, and transmission management software/hardware and 
treat them as a single system. 

The National Bureau of Standards (NBS) [Ref. 17] defines 
nine measures for evaluating computer network system perfor- 
mance. They are: 

1. Availability 

2. Transfer Rate of Information Bits (TRIB) 
3. Reliability 

4m Acetmacy (Or Residual Error Rate--RER) 
5. Channel-Establishment Time 

6. Network Delay 

7. Channel=-Turnaround Delay 

8. Transparency 


9. Metwork Security 





These nine measures do not represent all the possible per- 
formance measures, but they are considered to be the most 
essential and can be applied to any computer network and 
provide a basis for comparison with other networks. Ina 
local area network, a computer network manager might be 
imterested also in the utilization rates of the major network 
components, the throughput, the various network queue lengths, 
the response time, the mean transmission delay time, etc. 

All of the nine major and as many as are necessary of the 
numerous minor network performance measures should be con- 
sae@ered Ehroughout the acquisition process, from network 
Specification to network operation. The degree and the way 
in which these measures can be considered, varies during the 
process of going from a conceptual design to an actual imple- 
mentation in hardware and software. This variance is due to 
the fact that some performance measures can be applied to a 
network while it is still in the design phase with a greater 
accuracy than some of the other performance measures because 
some measures require an actual selection of hardware cr soft- 
ware before they can be considered accurately. With regard 
zo the numerous minor performance measures that can be con- 
Sidered, their use is dependent basically on the desires and 
needs of the network analyst or designer. 

With respect to a LAN for the implementation of SPLICE 
Fumetions, some particular performance measures are of great 
importance during the first stages of network design. At 


eumMse Stages, in fact, a designer primarily needs to estimate 
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message propagation delays and sustained point to point 
throughput rates. Based on this need this thesis in Chapter 
Iv will discuss the specifications of a simulation model for 
evaluating these performance measures. Also, after adopting 
a bus topology for the SPLICE LAN [Refs. 18,19], performance 
measures such as acquisition probability, waiting time and 
Emetetency of the channel [Ref. 11], can be considered. 

The above mentioned performance measures are described 
as follows: 

1. Avenlabality 

Availability is defined in Reference (20) as "the 
portion of a selected time interval during which the informa- 
tion vath is capable of performing its assigned data communi- 
cation function." Alternatively, availability can be defined 
in terms of the ratio MTTF/(MTTF+MTTR), where MTITF is the 
mean time to failure and MTTR is the mean time to repair a 
Gevice. Thus, availability can be improved by increasing 
MTITF and decreasing MTTR. 

Availability of a computer network is decreased not 
only by component failures but also by transmission overloads 
caused by either messages which contend for a transmission 
channel or by the inability of the transmission processing 
ecuipment to handle all the transmission requests. 

One common probiem in a data communication system is 
Bemetceumauash between very short term fallures of a system 


Such as those that cause a series of bit errors and longer 
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term failures that make a system unavailable [Ref. 16]. The 
Gistinction is arbitrary and is left to the user to define 
it in the most meaningful terms. Generally, events that 
cause errors on communication lines are not defined as failures 
unless the facility is unusable for more than several seconds 
or minutes. "Unusable" may mean totally unavailable or 
Waving such a high error rate that the effective transfer 
rate (TRIB) is reduced below some minimum acceptable value. 

2. Transfer Rate of Information Bits (TRIB) 

Transfer rate is defined as the ratio of the number 
of information bits accepted by a receiving terminal during 
a®stngie inftommatien transfer period to the duration of the 
transfer period. Transfer rate is expressed in bits per 
second. 

In calculating network transfer rate, the trans- 
mission channel capacity which is specified by the medium is 
the upper limit for the transfer rate. In an operating net- 
work, the transmission management procedures, propagation 
delay, channel turnaround time, and the retransmission of 
erroneous messages all subtract from the upper limit of this 
transfer rate. It should be noted that there are different 
detinitioms of what exactly constitutes an information trans- 
fer. Most communication engineers consider transmission 
block headers and trailers to be part of the useful informa- 
tion transferred. On the other hand, some applications- 
oriented users consider such headers and trailers as an overhead 


Pactor and not part of the useful information transferred. 
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See Kem rao lity 
Reliability is generally defined as the probability 
that a device will perform without failure for a specified 
time period or amount of usage. It is important to network 
users because it gives the probability that a requested task, 
using networking facilities, has been successfully completed. 
Expressed as a percentage, reliability differs from availa- 
bility in that it describes the performance of a network after 
it has accepted a request from its source. 
4. Accuracy 
Accuracy or Residual Error Rate (RER) is defined as 
the ratio of undetected error bits received at a terminal 
Station to the number of information bits transmitted to 
that terminal station. The value of the residual error rate 


is computed by the equation 


= ~ 
RER (€, +c + C,)7¢, 
where: 

ie = the number of erroneous information bits 

= accepted by the receiving terminal station. 
C = the number of information bits transmitted, 
a but not received by the terminal station. 
oa a the number of duplicate information bits 


accepted by the receiving terminal station, 
though they were not intended for 
duplication. 


c = the number of information bits in the total 
transmission. 
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Accuracy is expressed in the number of error bits per the 
number of ingdormation bits transmitted. 
>. Channel-Establishment Time 

Channel-establishment time is defined as the period 
of time required for network communication devices, trans- 
mission medium, and transmission management software/hardware 
to connect a calling terminal station with a called terminal 
station. The channel-establishment time includes both the 
time required to place the transmission request and the time 
required for the network to complete the connection. Channel- 
establishment time is normally expressed in terms of seconds 
for most networks but some newer networks are designed for 
estapdlishment times of not more than several hundred milli- 
seconds. 

In networks employing transmission techniques such 
as packet switching, the conventional interpretation of 
channel-establishment time does not apply. One view of such 
networks is that there is no establishment time, since tne 
network can almost always accept the next input message from 
the sending station with no delay. Another view is that this 
delay is imposed on every data excnange between stations, 
since virtual channels must be established. 

The significance of a channel-establishment time 
varies with the network user applications. If a user ex- 
cects to have many dialogs he may find channel-establisnment 


time to be very important. 
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6. Wetwork Delay 


Network delay or message transfer time is defined as 
the period of time required for a message to be transmitted 
from a source terminal station to a receiving terminal sta- 
tion. Network delay is usually expressed in terms of milli- 
seconds. In long-distance networks the actual value of 
Gelay depends on physical distances. 

In general, the network delay depends on the charac- 
Soameetes OL the terminal facilities, i.e., their buffer 
capacities, the volume of information being transferred, 
tme protocol required, and the reliability of the transmission 
medium. 

In an interactive environment involving a series of 
short conversational information exchanges, long network de- 
lays are undesirable. This is because the data input process 
has to be slowed down, becoming thus inconvenient and annoying 
to the user. 

= "eonnel=rurnaround Delay 

Channel-turnaround delay is defined as the time re- 
Guired by a half-duplex transmission channel to reverse its 
direction of transmission. This performance measure generally 
Gepends on the type of channel facilities which are used and 
it can range from very small values up to several hundred 
milliseconds. 

Channel-turnaround delay reduces the information 


transfer rate for half-duplex channels by increasing the time 
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required for a block of data acknowledgements. As with 
network delay, this delay can be reduced to some degree by 
using longer message blocks and larger storage buffers. 

oS  Transparcney 

Transparency 1s a totally qualitative term which 
@escribes: the lackwof code or procedural constraints which 
are imposed on network information processing by the network 
communication devices, transmission facilities, and trans- 
mission management software/hardware. 

The lack of transparency creates a need for changes 
in the network components or a need for user education in 
order to avoid conflict between the information processing 
and the communication pertions of the computer network. Most 
communication protocols have a problem with code transparency. 
For example, some protocol may not allow an end-of-transmission 
code to be used within the text of a message. In this case, 
the entire message must be scanned and modified in order to 
remove any illegal bit sequences. This detection and modifi- 
cation process, which may be handled in hardware or software, 
extends the length of the message and reduces the information 
transfer rate. 

9. Wletwork Security 

Network security is another totally qualitative term 
used to Ph cor ie the degree of protection provided for the 
information nandled in a computer network from unauthorized 


access. The importance of network security, of course, 
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GCepemas On the sensitivity of the information being handled. 
For most military and governmental networks, security is 
very important. 

mye Security of infommation is affected by the 
processing and communication devices, the transmission 
facilities, the transmisSion management software/hardware, 
the terminal station, the authorization that the users of a 
terminal station have to use it, and the isolation of user's 
files from each other. Of these network components, the 
communication devices, the transmission facilities, and 
the transmission management software/hardware are the most 
vulnerable to the unauthorized access of information. 

The most effective method of providing information 
@eqummity +s through information encryption. Encryption is 
best applied on an end-to-end basis, because it provides 
protection over the full length of the message's transmission 


path. 
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IV. SPECIFICATIONS OF THE LAN SIMULATION MODEL 


A. JN@RODUCPION 

Martin [Ref. 8] defines a simulation model to be: "a 
logical-mathematical representation of a concept, system, or 
Operation programmed for solution on a high-speed electronic 
computer." A simulation model can be constructed and applied 
during any phase of system design or predesign conceptualiza- 
tion. It depends upon the desired answers about the system 
to decide when a model has to be constructed. Thus, a simu- 
lation model can be constructed [Ref. 8]: 

1. Before the system is designed in order to determine 
Parameter sensitivity and to optimize or evaluate the system 
design. 

2. During the system design phase in order to test and 
experiment with system design concepts. 

3. After a system has been designed and built in order to 
supplement system test results and to evaluate overall system 
effectiveness. 

The SPLICE project at the Naval Postgraduate School, 
Monterey, California, is now in the predesign phase of a 
Leca- Area Network (LAN) system. This thesis, as part of 
the project, intends to support the design of a LAN imple- 
menting the SPLIC functions, by discussing in this chapter the 


specifications of a simulation model which will help in 


We 





parameter sensitivity analysis and LAN design optimization 
and evaluation. 
1. Background 

Simulation models have been widely used to study 
performance of computer systems. In the area of computer 
networks and especially of LANs, several simulation projects 
mamemoeen reported recently [Refs. 21, 22, 23] but they tend 
to place emphasis on the development and verification of the 
communication and access protocols. 

With respect to a LAN employing a bus architecture, 
as the one described in the SPLICE Request for Proposal [Ref. 
2] for the implementation of SPLICE functions, there has been 
little work done on the modeling of such a network. That 
is, to model the communication system as well as the functions 
of the nodes. Tropper [Ref. 21] suggests that: "A potentially 
effective approach to the modeling of such a system would be 
to use Jackson’s open queueing networks to model the nodes, 
and to use the appropriate time-delay formula to model the 
performance of the bus itself." 

2. Overview 

Following the approach proposed by Tropper this chap- 
ter will describe a Local Area Network (LAN) simulation model 
as an open queueing network. First, the simulation model 
resources are described in terms of the components which com- 
pose the model LAN, i.e., the node processor, the node-to- 


local network adaptor (LNA) interface, the LNA communications 
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software/hardware, and the transmission medium. Next, how 
these resources are modeled as an open network of queues is 
described. Then, the model workload is defined assuming an 
on-line environment with different classes of transactions. 
Finally, the transaction flow through the LAN simulation 
model and the selection of transaction classes are described 
in terms of the stochastic processes representing the flow 


through the queueing network. 


B. SIMULATION MODEL RESOURCES 

The simulation model resources are described below in 
terms of the components which compose the LAN model depicted 
nyeeqmmee 4.1. For that particular design the resources 
which serve user transactions and contribute to delay are 
the following: 

1. Node Processor, 

2. Node-to-Local Network Adaptor (LNA) Interface, 
3. LNA Communications Software/Hardware, 

4, Transmission medium. 

The resources of the model are characterized by their 
capacity to service requests, where, the request is charac- 
@-gizeqg Dy “ene resource capacity it consumes. A description 
of each resource and its characteristics follows. 

1. Node Processor 

A node processor in the LAN configuration of Figure 
4.1 can be a Host or Front-End Processor (FEP) or a processor 


implementing one or more SPLICE functicns (e.g., Terminal 
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Wee, Caca Base Mgt., etc. [Refs.1, 19]. Each node contributes 
to response delay by having to process applications and exe- 
Gute Haogh-level protocols residing in the node. A typical 
application in a LAN environment with a delay requirement is 
a query-response activity in which a user at a terminal 
connected to a node (FEP) inputs a query to a data base 
that resides on another node. Using the term "application" 
in general, different application processes reside in differ- 
ent nodes of the LAN along with nodal communications software. 
The execution of applications software residing in 

the nodes is initiated by requests from users at terminals 
or processes in other nodes. The resources which are con- 
sumed in the execution of the applications and nodal communi- 
cations software can be characterized by the following 
factors representing design parameters of the LAN: 

a. Number of instructions executed (path length), 

b. Node processing capacity, 

Ce Workload. mix. 
The workload mix represents the concurrent tasks which are 
executed in addition to the task being executed [Ref. 24]. 
Mie above, factoxzs, as well as factors characterizing the 
other model resources discussed later, will be used as user 
input values during the implementation phase of the LAN 
Simulation mocel. 

2ioeecetoseNA Interface 
The node-to-LNA interface is a physical serial half- 


duplex server. Hcwever, logically, it can support full 
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duplex data transfer. It can be characterized by delay 
components with: 

a Waiting time, 

b. Transmission time, 

Cc. Propagation time. 
The propégation time is usually negligible since the distance 
between the nodes and LNA is typically short. The waiting 
plus the transmission time is a function of: 

@. tne total traffic for each interface, and 

b. the transfer rate of the interface. 

3. LNA Communications Software/Hardware 
The LNA is assumed to be a microcomputer-based com- 
ponent which implements the data link layer. The protocol 
of this layer which resides in the LNA can be implemented 
in software or hardware. For software implementation, the 
LNA is characterized by the same factors discussed earlier in 
applications and nodal communications software. For the 
hardware implementations, the associated delay is character- 
ized by the hardware service rate. 
4. Transmission Medium 
The transmission medium serves as the physical communi- 

Cation path in the LAN. The delay associated with it is 
characterized by: 

peutrle’ Geta transfer rate of the transmission media, 

b. the overhead imposed by the access protocols, 


ey the distance between nodes. 





As it was stated earlier, all the characteristics 
of the LAN's model resources which can be considered as de- 
Sign parameters can be used as user input values during a 
Simulation run in order to evaluate the sensitivity of 


Gifferent performance measures. 


C. LAN RESOURCES MODELING 

[mis Section describes how the LAN resources specified 
earlier are modeled as an open network of queues. Different 
Kinds of processing activities performed by the LAN servers 
(1.e., the node processor, the node-to-LNA interface, the 
LNA processor, and the transmission medium), represent the 
delay components of the network. 

The queueing network which represents the LAN system is 
decomposed into modules corresponding to the network servers. 
For each module the classes of activities with their priority, 
the assumptions for the module, the delay equations, and an 
overhead factor are given below. The models for each of the 
four modules are specified as follows: 

1. Node Processor Modeling 

The node processor can be modeled as a single re- 
source multi-class queueing system with a preemptive-resume 
DElemley Gemvice discipline, as depicted in Figure 4.2. 
GC6@eermnng a SPLIC: LAN configuration a node can be a Front- 
End Processor (FEP), a Host computer, or a Mini-computer 
implementing SPLICE functions. Each of these nodes includes 


Central Processor (CP) and dedicated resources (e.g., Memory, 
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Disks). The delay imposed by the Disk access requirements 
must be included during a simulation run for calculating 
message delay and response time of any transaction processing. 
Also Disks depend upon the processor to handle interrupts for 
Disk I/O. This demand can be specified in the model as 
overnead (NOH: Node Overhead) to the node processor. This 
overhead, which also includes other LAN administrative func- 
tions, aftects the nominal «capacity of the node processor. 
Tae WeGe Eifective Processing Capacity (NEPC) is given [Ref. 


aay Day: 


NEPC = (1 - NOH)NIPS, 


where NIPS (Node Instructions Per Second) is the average 
number of machine instructions per second that the node 
orocessor can execute. 

A variety of activities can be considered for each 
node. In the LAN simulation model five classes of activities 
are specified wnich are serviced on a preemptive-resume 
scheme [Ref. 24]. These activities are: 

a. Link-In: Link level functions for messages inbound 
from the local LNA. 

b. Link-Out: Link level functions for messages outbound 
from the noce to the local LNA. 

Cc. Protocols-In: High level protocol functions for 


messages inbound from the local LNA. 
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G. Protocols-Out: High level protocol functions for 
messages outbound to the local LNA. 
e. Application: Transaction segment processing. 

ime Semwace time for each activity can be character- 
ized by the activity path length in machine instructions and 
Bae cetective processor capacity (NEPC) of the node processor. 

PePrtomity structure for servicing the five classes 
of activities has to be specified for every node in the LAN 
WEEP, Host, etc.). For example, the priority structure for 
a FEP node is assumed to be (from highest to lowest): 

a. Protocols-Out 
b. Link-Out 

©, @eplication 
a@. Puetocols-TIn 
ee. Siaiak=in. 

This priority structure is independent of any other 
priority scheme based upon the type of transactions and which 
will affect only the queue discipline of class of activities. 
The probable transaction priority is not considered here to 
avoid unnecessary complexity of the model. 

Assumptions for the node queueing model are as follows: 

a. The queueing system has a single waiting line and a 
Single server. 

b. Each class of activity is represented by an independent 
Pomesoen process with mean arrival rate Aj: 

c. The service times of each class of activity is represented 


me, aieeexmomential distribution with mean service time S;- 
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The rationale for choosing these assumptions con- 
Gernang arrival of classes of activities and service times 
ee well documented [Refs. 25, 26, 27, 29]. 

The equations for node delay, a4! for the various 


classes of activities are given [Ref. 25] by: 


’ Aoi 
As y/- ) p;) + ere oe O3) 


where for a node g the number of activity classes is j and 
the server utilization Pre A;S;- The A, is are determined 
by solving the balance equations for the network of queues 
associated with the node module. 
Zu HOGemEO-LNA Interface Modeling 

The node-to-LNA interface can be modeled as a single 
server queue. An overhead factor (IOH: Interface OverHead) 
can be considered on the nominal transfer rate of the inter- 


face for non-data bits. Thus, the Effective Transfer Rate 


(Pawx) cor €he interface is given by: 

Efe = (1 = ITOH) ITR, 
where ITR is the nominal Interface Transfer Rate in bits per 
second (bps). 


Pseumetions for the interface queueing model are the 


2Ol dewlng: 
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a. The queueing system has a singie waiting line and single 
server. 

6b. There are two classes of arrivals (messages from the 
node to the LAN and messages from the LNA to the node) 
without priority structure (i.e., the service discipline is 
Parst-Come, First=Served). 

c. Each arrival class is represented by an independent 
Poisson process with parameter Ais 

d. The service time of each arrival class 1s represented 
by an exponential distribution with mean service time S;. 

The equations for the interface delay of node g with 


7 arrival classes, Aga are given [Ref. 24] by: 


where 
Sy 
Af = dy + do 
S = (4,8, +4,55,5)A° 
3. LNA Processor Modeling 


The LNA processor can be modeled as a single resource, 
multi-class queueing system with a preemptive-resume Br lerml CY, 
structure as the one given in Figure 4.2. An overhead factor 


(ACH: Adaptor OverHead) can be considered on the processing 


63 








capacity of the LNA processor, which includes system's admin- 
istration overhead functions. Thus, the effective processing 
capacity (AEPC: Adaptor Effective Processing Capacity) for 


a LNA processor is given by: 


AEPC = (1 - AOH) AIPS, 


where AIPS is the average number of machine instructions per 
second that the LNA processor can execute. 

For the LNA module in the simulation model five 
classes of activities can be specified. A list of these 
activities follows [Ref. 24]: 

a. Network Link-In: Link level functions for messages 
inbound to the LNA from the network transmission medium. 

6b. Network Link-Out: Link level functions for messages 
outbound from the LNA to the network. 

c. Node Link-In: Link level functions for messages 
inbound to the LNA from the node side. 

dad. Node Link-Out: Link level functions for messages 
outbound from the LNA to the node. 

©. Emeeocol:s Execution of data link protocol for messages 
from the network side and the node side. There is a FCFS 
Gm@iecaplane Wiitban this class of activity. 
The priority structure of classes of activities for a LNA 
processor is assumed to be (from highest to lowest): 

a. Network Link-Out 


be Broce Link=-Out 
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G. Network Link-In 
ad. Node Link-In 
ea Hrotocol 

Again the priority structure is independent of any 
other priority scheme which can be imposed at transaction 
level. 

The mathematical assumptions as well as the equations 
for LNA model are the same as those given earlier for the 
node model. 

4. Transmission Medium Modeling 

The combination of the physical protocol layer of 
the OSI model and the transmission medium can be modeled as 
a single server queue. The physical protocol layer is imple- 
mented in hardware and is referred to as the Media Access 
Unit (MAU). The transmisSion medium access scheme considered 
in the simulation model is the Carrier Sense Multiple Access 
with Collision Detection (CSMA/CD) which has been modeled 
extensively [Ref. 21]. 

The assumptions for the queueing analysis of the 
CSMA/CD access scheme are [Ref. 21]: 

a. Poisson arrivals over an infinite population. 

So @eetictete collision detection time (compared to the 
bus propagation time). 

@e CGaammel sensing 1s instantaneous. 

d. Propagation time between any two nodes is uniform anc 


equal to the maximum value. 


= 








e. Retransmission of packets iS ccording to the Binary 
Eeponemcial Backoff probability rule. 

£. The random interval parameters for the backoff algorithm 
1s uniformly distributed and the same for all MAU's. 

A priority message system can be supported at the 
transmission medium level by varying each MAU's backoff 
algorithm (assumptions "e" and "f" above) and letting some 
of them have linear instead of exponential backoff algorithm 
fem. 22). 

An algorithm for the CSMA/CD access scheme is given 
[Ret: 24} in Figure 4.3. 

The equation for the time delay, D, in terms of the 
system throughput, the offered load, and other system 


parameters is given by the formula [Ref. 26]: 


Dewees (Al + A2 + A3)T 
where 
Al = the normalized wasted time due to collisions, 
A2 = the dead time due to retransmissions and 


rescheduling, 
A3 = the propagation and transmission time, and 
Sy = the packet length. 


Givwem tnat: 
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Figure 4.3. CSMA/CD Algorithm 
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Nl = the average number of times a packet encounters 
a collision Or busy state, 


N2 = the average number of times a packet encounters 
as%eollisaon, 


Rl = the normalized mean retrial interval after 
detecting a busy condition, 


R2 = the normalized mean retrial interval after 
detecting a collision, 


a = the progagation delay, 
G = the offered channel traffic (load), and 
S = the throughput. 


It follows that: 


Al = N2(W + a) 
No+1 
Se = R2(2 — we — N2RL 
A3 = atl 
where: 
eee te. 7°) /e = ae °° 
me = G/S- l 
N2 = (1 - aG) e aos il 
ana the normalized throughout (S = ’AT) is related to the 


normalized offered packet traffic (including retransmissions) , 


G) By the ecuation [Ref. 27]: 
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Tee 
C. MODEL WCRKLOAD 

For the particular LAN configuration to be modeled 
(Figure 4.1), the network user's transactions, when trans- 
lated into access and processing requirements, can be charac- 
terized by the type and the amount of system resources the 
network will have to provide in order to fulfill these re- 
Guirements. The sum of system resource requirements gener- 
ated by all the network users represents the system or 
network workload. Generally, the workload of a computer 
system has certain basic statistical characteristics that 
Go not change greatly over short periods of time. The use of 
such characteristics make it possible to do the following 
(eet. 28]: 

1. To characterize the system workload by statistical 
Gistributions of requirements placed on individual system 
resources, and 

2. To define a unit of work and then express the workload 
G@m@eacteristics in relation to this unit. 

Themwom<load characterization of a SPLICE LAN configura- 
tion would be based on an on-line and batch input environ- 
ments. The simulation model specified in this chapter 
considers an on-line environment with twelve different 
eleissese of transactions [Ref. 2]. This is because it was 


felt that to include the batch input environment added detail 
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and complexity to the simulation model which was unnecessary 
for the fulfillment of analysis objectives during the early 
Seeages Of SPLICE LAN design. 

Eacn class of transaction requires service from resources 
of one or more network nodes and is divided into a number 
of transaction segments (processes). A description of what 
constitutes a transaction class and how the on-line workload 
is specified follows. 

l. ‘Transactven Class 

The transactions input from the terminals at the FEP 

node of the LAN are described as a series of transaction 
classes. A transaction can be characterized according to 
tee seer ival rate whach can be converted into probability of 
occurrence or cumulative probability of occurrence, and the 
number of LAN node requests (data path) it requires. For 
example, supvose the LAN contains five nodes. Table 4.1 
shows the twelve transaction classes and their hypothetical 
arrival rates, probabilities of occurrence, and node re- 
Guests. For example, transaction class TC2 describes those 
ransactions which require three node requests (1.e., data 
Been Weed 1=2-5). The data path is determined from the re- 
quired LAN resources by the segments (processes) of this 
Peemememion class. The probability of such a transaction (TC2) 
to occur in the transaction input stream of node #1 (FEP) is 


Five percent. 
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TABLE 4.1 


On-Line Workload Characterization 
(Hypothetical Data) 


TRANSACTION PEAK HOUR PROBABILITY CUMULATIVE LAN NODE 
CLASS TRANSACTION OF PROBABILITY REQUEST 
ARRIVAL RATE OCCURRENCE OF (NODE- 
(TRANS/SEC) OCCURRENCE NUMBER) 
Te) 290 7888 Ope iy OTe re 
mC 2 0.88445 OxG 05 Ore 2 es, 
mes 0. Si 364 C205 O25 i~3-3 
TC4 0.41312 U20Z2 OF) 1=2=3-5 
eo PS Sees Oe Oo Sie Veo oe 
TC6 i 395634 Oral 0.47 eS a oe: 
Te/ Om 7 W285 0.04 OGioL 1-3-4-5 
TCs On eSAehO. O7n0'5 O26 es 
pi Oo, 0228633 00 Zz Oz 56 1-4-5 
me10 e239 39 OPn0iS 0.266 1-2-4-5 
PC) b On 6Od43 OF0 5 Onev6 9 is Falco 8 
mG J 2 Beio4 292 Os Gel pae0) Dee 


22 Wieensaeceiton Segment 
Bach class of transaction is composed of a series of 

transaction segments. These segments are small units of 
work within a transaction wnich compete for LAN resources. 
Reference (2) recognizes eight types of transaction segments, 
the following: 

a. ~gpait 

ae 6 Valei@ation. read 


e. Vale cation 


fu 


Emwaor messace 








e. Processing read 
i. Precessing 

g. File write 

Rt Pekmat output. 

the process load for each transaction class along 

with their segments characteristics and corresponding hypo- 
thetical values are given in Tables 4.2 through 4.13. It 
Gan ©© seem that a transaction class is divided into four to 
eight segments with different message length, characteris- 


tics, and processing requirements for each. 


E. TRANSACTION FLOW 

A transaction flow through the LAN system simulation model 
is a flow through the network of queues, each modeling one 
resource of the system model. The queueing network which 
represents the LAN system, as it was discussed earlier, is 
not considered and modeled as a whole, but it 1s decomposed 
into modules which are analyzed in isolation. The focus in 
this approach is on the stochastic processes representing 
the flow through each module where the output of one module 
represents the input to a subsequent module. 

The flow in the simulation model can be portrayed as a 
series of discrete events. The occurrence or timing of these 
events is on a next event scheduled basis. The next event 
approach to simulation is discussed briefly by Fishman [Ref. 
Gl eso She oceurrence of events 1s governed according to 


the varicus statistical distributicns of requirements which 
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TABLE 4.2 


Process Load for Transaction Class l 


TRANSACTION 
SEGMENT 


}. Bdtet 


Zz. Validgation 
read 


3. Val réaeieon 


4. Error Msg 


5. Processing 
read 

6. Processing 

7. File write 

oS. fOrmeae OUTPUT 


CHARACTERISTICS 

a. Message length 

Ee Be. Of InSeructlons 

Cc $ Of fail 

a. No. of records 

b. Record length 

Cc. We. GE instrwetions 
per access 

ae 2 of Lael 

a. Wo. of instrwetions 

Is) 2 % Of fail 

an,  NO,OL 1nSeruct ions 

b. Message length 

a. No. of. records 

b. Record length 

& Wo. of instrwetiens 

a WNMo.c-of insteactlons 

aS We. of imsetructions 

b. No. of modified record 

G. length of meditied record 

ad. No. 6£ adds 

e. Length of added record 

ft Hos of indwees 

a. No. of instrucerons 

b. Message Length 

c. Wo. of reeords 


73 








TABRE 4.3 


Peocess Load for Transaction Class 2 


TRANSACTION 
SEGMENT CHARACTERISTICS VALUE 

1. wea t a. Message length 200 
Db. We. Of InSeructions 50 
C Sp 0m fail IL 
2. Validation ae No. of rFecords 10 
read b. Record length 250 

C No. Of #@imS@ructions 
per access 20 
ad: t80£f£ Ear! l 
3. Valsadation a. Me. Of ABnstructions 0 
be. @280f faz 0 
4. Error Msg a. N@®™ of instructions 5 
b. Message length 80 


5. Processing a. Neweet reeords 0 
read b. Record length 0 
oe No. of inemructions 0 


6. Processing a. No. of instructions 0 


7. File write a Mo. of imetructions 0 
b No. of modified record 0 
G. Wengen Of mogdatiedserecord 0 
dad. No. of adds 0 
2 Length of added record 0 
fe 0 


No. of indices 


8. Format output Qa. ©. of inSermetions 30 
b. Message length 1000 
Wo. of records iL 








TABLE 4.4 


Pr@ee@~ess Load for Transaction Class 3 


TRANSACTION 
SEGMENT 


1. dat 


2. Valrdation 
read 


3, Validatéon 


®. Goror Meg 


5. Processing read 
6. Processing 

7. File write 

8. PormMat output 


CHARACTERISTICS 

a. Message length 

b No. Gf inStwactions 

Co teolt fart 

a. No. of records 

b Record length 

c. Ne. ef iInmstmeactions 
per access 

Ga. vOtmebarlk 

as Me. Ofseinstruetwvons 

Dp. ww Of fail 

@ Me. of instructions 

b. Message length 

a. Neo. of reeerds 

b. Record length 

GC. NM@®. Of ime eEveceEtons 

a. Me. of imetructions 

a. No. of insieuiceaons 

b. No. of modified record 

Cc. Bengeh Of m@dified record 

a: WNowsef adds 

e. Length of added record 

£. No. of indices 

a. NO. of UNSeructions 

b. Message length 

c. No. of records 





TABLE 4.5 


Process Load for Transaction Class 4 


TRANSACTION 
SEGMENT 


CHARACTERISTICS 


1. Weet 


2. Vakrdation 
read 


=. Valli @datavon 


S. Eprer lpg 


5. Processing 
read 
6. Processing 


7. Frle Write 


So ,fPOmat Output 


a. Message length 

Db. WoO. Of insteuccions 

Cc. 3 “Of Lauke 

a. No. of records 

be, Record length 

Cc. Ne. Gf BPMStructrvons 
per access 

a. @FOf fail 

a. We. of instrwetions 

bey . sor faq. 

ae We. Os instructions 

b. Message length 

a. WN@. of records 

b. Record length 

G. Ne.>%OF AInStrucEteions 

a. We. Of instructions 

= Wo. Of LASETUCEL ONS 

be Wo. of modified record 

c. Length of modified record 

qd. WoO. cf “adds 

e. Length of added record 

f. MO. GE indwees 

a. WO. of INSEructions 

b. Message length 

G No. of records 
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500 


500 





TABLE 4.6 


Process Load for Transaction Class 5 


TRANSACTION 
SEGMENT 


Lt. Edaet 


2. Validatwzvon 


read 


3. Velldidation 


*. Emror Msg 


5. Processing 


read 
6. Processing 
7. Fibe Write 


8. Format output 


CGHARACTERISTICS 

a. Message length 

be New ot InSteructions 

G.. £tOL tant 

a. MO. of records 

b. Record length 

©. We. Gf instructions 
per access 

Ge & Of farl 

ef Wo. of instructions 

pe @8Rot fal 

ae Wo. CE INSteENcELoOnS 

b. Message length 

a. Neo. of records 

b. Record length 

Ge. Wo. of 1nS tredectacns 

a. WM. of INSEruct rons 

a. Wo. Of Imstructions 

b. We. Of medified recerd 

eo Leiden cemmodi pled second 

ee Wo. of adds 

e. Length of added record 

£. No. @f iInevees 

a. Wo. of imeteructions 

b. Message length 

€;. Ne. of records 
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PAB EE. 477 


Process Load for Transaction Class 6 


TRANSACTION 
SEGMENT 


gf. Edit 


Zz. Vaelidat »eon 
read 


3. Vabidation 


*. Emgror Msg 


5. Processing 
read 
6. Processing 


7. File write 


8. Format output 


CHARACTERISTICS 

a. Message length 

be. 6. Of insteructazons 

Cc tor fawel 

a. No. of records 

Bb: Wecord length 

©. ©. of instruceions 
per access 

Ge @ of fail 

a. We. of inStructions 

Db Ror fait 

aoe NO. Of ImMSECUecEIONS 

b. Message length 

a. No. eof reeords 

b. Record length 

GG. Geo. Of simstructions 

a, @©. Of inStmwections 

a: Wo. of iImSstErucETONs 

b. No. of modified record 

¢. Length of modified record 

a. Wo. Of adds 

e. Length of added record 

f. No. of indices 

a. Wo. of iImetrewctions 

b. Message length 

¢. Mo. of recerds 
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TABLE 4.8 


Process Load for Transaction Class 7 


TRANSACTION 
SEGMENT 


I, @edet 


2. Vabladation 
read 


3. VeliGdation 


>. Heror Msg 


5. Processing 
read 
6. Processing 


7. File write 


8. Format output 


CHARACTERISTICS 

a. Message length 

b. NO. Of instructions 

Cc % Of fal 

a. No. of records 

b. Record length 

Cc. Wo. of aaistructions 
per access 

Gs-.(snOr Patt 

@;: ©. OCfeINSEZUCEIONS 

Bb. . So8 fail 

a. Wo. of instmwetions 

b. Message length 

a. oO. Of recenas 

b. Record length 

C. Mo.°of instructions 

a. No. Of “Inservice rons 

a. Mon Of Last suuceions 

b. No. of modified record 

c. Length of modified record 

qd. Wo. ef adds 
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are placed on individual system resources. This section will 
discuss transaction flow within the simulation model in 
térmms of transaction class selection and processing. 
1. Transaction Class Selection 

The selection and processing of a transaction in- 
volves the determination of its class and consequently the 
transaction segments needed, each with their specific 
processing requirements. 

The arrival of transactions at their initial input 
into the front-end processor can be characterized by a 
Poisson process, assuming independent and random inputs. 
Then it can be shown [Ref. 29] that the transaction inter- 


arrival times (tT) are exponentially distributed about a 


mean interarrival time. This distribution is described by 
pen = Pr <s) = ee Seo 
where: 
P(S) = the probability that a transaction will 


aeerive within time S. 


= the transaction arrival rate at the 
bavei1cw@lar processor. 


> 
| 


Since the transactions are assumed to enter the processor's 
input queue independently and at random, P(S) must be a 
random number between 0 and 1. Consequently, 1-P(S) is a 


random number R. Thus, 
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7 
- 
4 


-AS 


P(S) = l-e 
@is 

ema 1 - p(s) = R 
or 

=AS = IlneR 
or 

See =) ln RA 


where S is the time increment added to the present time to 
schedule the arrival of the next transaction at the Front- 
Emer Processor (FEP). 

The class of the transaction input at the FEP is 
Getermaned by referring to their cumulative probability of 
Seeucremce WHaole 4.1) according to a step probability 
function. This function allows for the independent random 
selection of transaction class while maintains their relative 
probabilities of occurrence. 

After a transaction has been assigned a class, the 
COnpresponmeeng segments (Tables 4.2 through 4.13) of this 
transaction begin processing following the predetermined 


Gata path specified in Table 4.1 (LAN node requests). 
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When all of the node requests of a particular trans- 
action have completed processing, the various statistics 
associated with the transaction and the LAN system model are 
accumulated and updated respectively and the transaction is 


output from the model. 
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V. IMPLEMENTATION OF THE SIMULATION MODEL 


iicwcires Generali phases in the construction of a simu- 
lation model are: conceptualization (specifications), 
implementation, and finally execution of the production runs 
on the computer with interpretation and evaluation of simu- 
lation outcomes. The conceptualization of the model was 
discussed in the previous chapter, where the specifications 
of a simulation model for a local area network were given. 
The implementation phase involves the transformation of 
conceptual model into a tangible computer simulation that is 
ready to generate simulation outputs during the final phase 
Ge ches construction. 

It is beyond the scope of this thesis to implement and 
conduct experiments with the specified model. However, some 
comments on aspects of the last two phases of model construc- 
tion is considered essential for an overall presentation 
and understanding of a simulation model. This chapter will 
Pee casei ss procramming of the model in terms of simula- 
tion languages available, and will comment on simulation 


experiments. 


A. PROGRAMMING THE MODEL 
Programming is one of the major tasks in the implementa-~- 
Eton Paase Of Model construction. It includes all the pro- 


cedures recuired to transform the logical statements and 
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mathematical formulations of the model to some computer 
language statements. Martin [Ref. 8] recognizes the follow- 
ing procedures to be involved in a programming task: 

1. Modularization of the model in a programming context 
in which the model is subdivided into logical units and 
subunits. 

2. Construction of flow chart diagrams that represent 
the program flow of the model. 

3- Codimg of the program for the particular computer. 

4, Checking the validity of the program and making 
necessary revisions. 

>. “Bseparatwvon of input and output formats. 

A major step before starting actual programming is the 
determination of a computer system to be used for implemen- 
tation of the model. For the particular LAN simulation model, 
Specified in Chapter IV as part of the SPLICE project at the 
Naval Postgraduate School, it would be implemented using the 
facilities: available at the school, i.e., IBM 3033 computer 
System ane GPSS (General Purpose Systems Simulator) or 
SIMSCRIPT simulation languages. Simulation languages, as 
Gistinguished from general-purpose languages, are problem 
Oriented. Such languages are usually written ina largely 
computer independent notation for a particular problem area, 
and contain statements or constructs appropriate for formu- 
VatemcGSselGerems to specific types of problems. Of course 


general-purpose languages such as FORTRAN can be used in 
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Simulation modeling, but the simulation languages designed 
specifically for the purpose of computer simulation provide 
certain useful features [Ref. 3]. Among them: 

1. Reducing the programming task and providing conceptual 
guidance. 

26 Gidangean defining the classes of entities within the 
eysem and providing flexibility for change. 

3. Describing the relationship of entities to one another 
and to their common environment. 

Various simulation languages are operational at the 
present time. The most popular are GPSS, a process-oriented 
language, and SIMSCRIPT, an event-oriented language, both 
available at NPS's Computer Center. Table 5.1 gives a com- 
parative list of some features of GPSS and SIMSCRIPT as 
briefly summarized by Tocher [Ref. 30]. Each language has 
certain characteristics and applications, and each of them 
can be extremely useful when applied properly. A brief 
description of each of these two simulation languages is 
given below: 

is, 6s GPSS) Simulation Language 

General Purpose Systems Simulator (GPSS), was developed 
originally by G. Gordon at IBM and is one of the most popular 
Giscrete-event simulation languages. GPSS is process oriented, 
G@emeainimag a sumply of flow chart-like blocks [Ref. 31]. It 
also provides a large variety of autonomously generated 


measurements about the simulated model. GPSS can also be 
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TABME S21 


Features of GPSS and SIMSCRIPT 


GPSS SMSC RLP Er 
What are the dominant types 
of activities? Transaction Transaction 
How is the system repre- 
sented? Flow chart FORTRAN-based 
What uniform random 
number generation 
technique is used? Multiplicative Multiplicative 
How many random number 
generators are available? Indefinite il 
Is there uniform sampling? Yes Yes 
Is there any statistical 
Gerrectung in hestogram 
Lorin? Yes No 
Can the mean be computed? Yes Yes 
Can the standard 
deviation be 
computed? Yes Yes 
What is the limit on 
the number of 
GQaist ribwtioens.? 100 None 
Can arithmetic tests 
be performed? Yes Yes 
Can set inclusion 
tests be performed? No Yes 
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viewed as a program that employs a language which is de- 
sulemed to “describe simulation models of a system. The user 
constructs a logical model of the system using a block 
Giagram consisting of specific block types in which each 
block type represents some basic system action. 

GPSS elements are blocks, transactions, and equip- 
ment. Specific block types have a name, a characteristic 
symbol, and a block number. Each block has a designated 
block time that indicates the number of time units required 
for action represented by the block. The block time is not 
constant; it may vary in a random or nonrandom manner. 
Transactions are basic units that move through the system. 
Equipment elements contain facilities and stores. Facilities 
can handle one transaction at a time, whereas stores can 
handle many transactions simultaneously. 

Since its original version, GPSS has appeared in 
Saescoucnt, mere powerful versions: GPSS-II, -III, -Iv, -V, 
and -360. Current versions provide limited capability for 
using FORTRAN subroutines. Also there is a version which 
eaeemen a GY display unit, provides conversational features, 
user in@eractive input, and control. 

2. SIMSCRIPT Simulation Language 

SIMSCRIPT was developed by H. Markowitz, G. Hausner, 
ame He Karr at the RAND Corporation. It was one of the 
original discrete-event simulation languages, l.e., is based 


upon the notion that every model system is composed of 
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elements with numerical values that are subject to periodic 
Change. The state of a system is described in terms of 
emeaties, attributes, and sets. The status of a system is 
changed at discrete points in simulated time by the occur- 
pemee of an event. Entities are objects which compose the 
system, and may be classified as temporary or permanent during 
the simulation. Attributes are properties associated with 
entities or items that describe entities. Sets are groups 

of entities. Status is the numerical description of the simu- 
lated svstem. Events are series of statements grouped to- 
gether which modify the status of the simulated system at 
various points in simulated time. There are two types of 
events possible: exogenous (from outside the simulation sys- 
tem), and endogenous (from within the simulation system). 

The occurrence of these events is governed by a SIMSCRIPT 
provided timing routine. This timing routine automatically 
keeps track of simulated time and causes the various events 
to occur as thev are scheduled by the simulation program. 

fie ditesesentwcames Of events are enumerated in an events 
list and a separate event subroutine has to be written for 
Gaek evemee By contrast with GPSS, SIMSCRIPT does not 


provide for any automatic statistical anaiysis. 


SB. SIMULATION EXPERIMENTS 
The final phase in the development of the local area net- 
work simulation model is to conduct a series of simulation 


experiments which will be helpful in drawing conclusions about 
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the System modeled. That is, for the particular SPLICE LAN 
design, potential bottlenecks and other design weaknesses 
can be identified as well as determining the adequacy of the 
components of the design relative to specific delay require- 
ments. 

In general, simulation experiments are conducted for a 
wide variety of purposes, some of which are the following 
[Ret. 3]: 

1. Evaluation: determining if a proposed system design 
performs well in an absolute sense when evaluated against 
Specmeic criteria. 

2. Comparison: comparing competitive systems designed to 
carry out a specified function, or comparing several pro- 
posed operating policies or procedures. 

3. Prediction: estimating the performance of the system 
unger some projected set of conditions. 

4. Sensitivity analysis: determining which are the most 
Significant factors affecting overall system performance. 
>. Cpitammization: determining exactly which combination 
of factor levels will produce the best overall response of 
tme svstem. 

In the experimentation phase of model construction sys- 
tem performance criteria must be established that will be 
used in rating various alternative local area network designs. 
A frequently employed perfeormance measure in most local area 


network simulation studies is time delay versus throughput 


trade-off. 
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This thesis recommends experiments that characterize 
local area network utilization and throughput which can be 


conducted using the specified simulation model. 


che: 





Vi. CONGEUSEONS 


The specifications of a Local Area Network (LAN) simu- 
lation model have been given. The model is specified to 
allow the evaluation of alternative network designs through 
either modifying the workload presented to the network or 
modifying the network configuration. 

The level of system resolution to be represented in the 
model as well as how detailed must the model be to give a 
valid representation of the system depends on the questions 
to be asked of the model. The more complex a model becomes 
the less able it is to answer new and unexpected questions. 
For the particular SPLICE LAN deSign in its present state 
of development it is felt the simulation model is adequate 
for obtaining a basic understanding of network performance. 

It should be emphasized though that the construction of 
a simulation model is an iterative process. The LAN model 
Specified in this thesis can be considered as a low-level 
first generation model which ailows for future growth by 
preceedame te a more complex and sophisticated level in 


Future generation models. 
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